New Version of Are Daily Stand-Ups Harming Your Team?
I wrote a short post called “Is The Daily Stand-Up Harming Your Team”. After getting some feedback on it, I have refactored it and here is the new version. (I have deprecated the old version):
The Purpose of Stand-Ups
Here is a short definition from “Planning Extreme Programming” (Beck/Fowler 2001):
Have a short meeting every day so everybody knows what’s going on, and what’s not.
The Daily Stand-Up meeting is meant to be a very short meeting with several related purposes:
-
Team Alignment or “sync-up” – who is working on what, what’s been done, what do we need to discuss…
-
Expose issues that need to be handled (impediments, etc.)
-
Eliminate other meetings that can “hog time”
- Allow some other people not on the team to hear about things the team is doing
- etc – put your own things you value about Stand-Ups here.
Those all bundle up to one thing: Daily communication about important stuff.
Good Communication Is Essential for Software Development
Programming is done by individuals who must communicate with each other. Finding ways to communicate well makes things a lot better. The Agile Manifesto itself puts a lot of focus on the importance of good communication. A quick glance at the Manifesto and Principles makes this clear: Individuals and Interactions, Customer Collaboration, Responding to Change, business people and developers must work together daily, face-to-face conversation, self-organizing teams, the team reflects on how to become more effective. Almost every Value and Principle somehow reiterates the need for good communication.
I “buy in” to all of this. In my opinion, a BIG part of becoming and staying effective in software development is to continually improve our ability to communicate – team member to team member, team to customer, business people to team, and whatever combination you need. As we find problems with traditional communication methods (such as meetings, emails, documents, charts, yelling, etc.) we need to explore “better”. Even more important, when we find something is working for us we should explore how to make it even better. Whatever we do, no matter how good, there is always “better”.
A little Background:
A number of years ago (about 10 or 11 years I guess) I started visiting Agile/Scrum/XP development teams/departments and observing Stand-Ups and other meetings – just for the fun of it . I’d been doing XP for several years, and loved visiting other teams – mostly for my own enjoyment, but also to learn how others were doing things. I have visited a number of teams and departments over the years – about 20 or so. I am not a consultant as such – so these were casual visits.
What I noticed in visiting teams doing Stand-Ups
I noticed a few harmful things in a majority of the Daily Stand-Up meetings I observed. Things such as:
- Individuals taking a long time (5 or more minutes each rather than 2 minutes)
- Meeting taking too long (45-60 minute standups – more like “lean-ups” after a while)
- Too Much Detail, Not enough Detail
- People not showing up on time
- Too many people (10 or 20 people) – attendees are hearing about stuff that isn’t relevant to them.
- Mumbling and Grunting
- Discussions between 2 or 3 team members to resolve some aspect of something
- Yelling
- No one is interested in what the others are saying (and often without any reason to be interested)
- Issues brought up are never addressed
- Needed follow-up meetings never occur
- Same report every day
- Dogmatic enforcement of rules
- … I can go on and on. I used to take notes and had about 20 different issues that commonly showed up.
I have seen a lot of these same dysfunctions on teams I ‘ve worked with over the years. Some of these teams have discovered ways to reduce or even eliminate most of these “Daily Stand-Up” dysfunctions.
There have been countless blog posts, book chapters, workshops, conference sessions, etc. on solving “Daily Stand-Up” problems – which is great. It is a good thing to recognize problems and solve them.
But I think there is a “next step” we can take. For me, when I see something causing this much trouble for so many different folks and teams, in so many dfferent ways, over and over again – I start to wonder if there is something we are all missing.
My first question was: Why do so many teams have so many problems with Stand-Ups???
The Daily Stand-up is a fixture in most Agile/XP/Scrum environments. It has a very simple purpose, and is a very simple meeting – and yet, many teams continue to have these problems. Why??? Well, that is too complex for me to cover completely here (I could cover some of that in a future post if anyone is interested) – what I want do do instead is share what I have discovered after investigating this for about 5 or 6 years. I’ve done a number of “5-whys” root-cause analysis sessions, and retrospectives on vairous Stand-Up problems, and I’ve read as much as I could find on the topic.
Here is what I think I have found:
At the bottom of many of my “5-why” Sessions
You’ve probably all done something like a 5-Whys analysis. From Wikipedia:
The 5 Whys is a question-asking technique used to explore the cause-and-effect relationships underlying a particular problem. The primary goal of the technique is to determine the root cause of a defect or problem.
With manny of the dysfunctions I was investigating, I would end up at about the same place. Typical starting questions were: “Why do team members think the Stand-Up is boring”, or “Why do we have too many things we need to cover in the Stand-Up”, or “Why does our Stand-Up take so long”. As often as not, the near the bottom of my “5-why” session was this question: “Why do we think we NEED Stand-Ups?”, and the answer I often end up with is “The Daily Stand-up exists because we are not in continuous alignment. We need the meeting because there are things we are not communicating during the day”. So that leads to this question: “Why aren’t we in continuous alignment?”.
Why aren’t we in continuous alignment?
That is: If we could be in “continuous alignment”, and find we have nothing to communicate in the Daily Stand-Up, we wouldn’t have any of the dysfunctions of the Daily Stand-Up because we would no longer be holding them.
Would it be good to be in Continuous Alignment? What if it was possible to effectively and efficiently stay in “continuous alignment” how would that change our thinking about the need for Daily Stand-ups? Some teams have been very happy with the Daily Stand-Up, and find that it brings a lot of value. Still, even in those environments, there is always room for improvement. In Agile/Lean/XP/Scrum it is important to continuously scrutinize the practices we are using and innovate even better ways to do things.
It seems worthwhile to me to at least explore the possibility that there is something even better than well functioning Daily Stand-Ups.
Are You Saying We Should Just Stop Doing Our Daily Stand-Up?
Of course not. But this hints at an important “next step”: Let’s figure out how to have continuous alignment. Some common practices that many teams already use are things like: Task Boards that everyone can see and that are dynamically updated as work gets done, sitting together (so you can hear anything imporant that is happening), pair-programming, switching up pairs frequently (several times a day), raising “blocking issues”(and solving them) immediately rather than waiting until a meeting, TDD, CI, and whatever you can think of. The more complete and meaningful you can be with dynamic communication the better chance you have of being in continuous alignment.
Of course – these practices will not necessarily elminate the need for the Daily Stand-Up – lots of teams use them and still find they have a need for the Stand-Up, but they will very likely resolve a lot of the traditional “Daily Stand-Up” issues I listed above. A shorter Daily Stand-Up that is more meaningful for the team could be a worthwhileend result.
What are the Costs of “Continuous Alignment”
The “costs” for being in “continuous alignment” should be small – it’s a matter of discovering the things you need to communicate and a mechanism for doing having those communications. Most Agile teams are already doing a lot of the practices that help provide good communication throughout the day – it’s just a matter of fine-tuning them, or “turning them up a notch”. Becomming better at communication is a benefit in any team situation. We can choose the Daily Stand-Up over Continuous Alignment, vice versa, or both in some combination. Each time we find something in a Daily Stand-up that should have been communicated earlier we should look into it and figure out how we could have communicated it dynamically. The main cost is that you’ll need to pay a lot more attention for a while – but as you smooth things out it will become natural to gravitate to better forms of communication.
What My Experience Has Shown Me
If we have continuous alignment, there is little need for a Daily Stand-Up. When it gets to the point where we gather in the morning for our Daily Stand-up and consistently find we have nothing useful to share it is likely that the practice can be retired. In the “Lean” sense, a practice is waste if it brings no value. Waste is not neutral, it diminishes the team – it is a cost that has no return. With my current team we’ve worked without Stand-Ups for over a year and have found no need for them.
Here are some of the practices we follow that allow us to do this:
- We work together througout the day
- We meet at any time there is something important that needs to be addressed
- We pay attention to update our dynamic “information radiators” as we work
- Anytime we need help we ask for help
- Anytime someone asks for help, we help
- We meet face-to-face for all meetings whenever possible
- We all work on the same thing until it is done or there is nothing further that can be done with it (“one story at a time”)
- We solve blocking items immediately if possible, and communicate with each other when anything changes
My Advice – A Few Ideas
If you want my advice it is this:
- Examine your Daily Stand-Ups regularly
- Pay attention to anything that comes up in the Stand-Up that should have been communicated earlier
- Hold a retrospective with a focus on the Stand-Up – do this several times a year
- Find better “dynamic” communication techniques
- If you are not doing pair-programming, you should practice it and learn how to make it work for you
- Switch up pairs frequently – every few hours
- If you can’t stand the idea of pair-programming, do some Code Dojos and Katas to experiment with it
- Sit together – all team members working within easy talking distance of each other
- Do more work as a team – QA and Dev pairing, “Customer” and Dev pairing, QA/Dev/Customer teaming, and so on.
- Improve your “information radiators” and keep them updated throughout the day
- Try “Mob Programming” where everyone works at the same computer all together at the same time
- Talk with each other during the day
That’s just a start. You will probably come up with better ideas than I have. Please let me know what you find.
So: Are Daily Stand-Ups Harming Your Team?
Might be. If there are better ways to do things, and you don’t at least explore them, then you might be stuck with practices that are not as useful as they could be. In the old days, I heard a lof of “That’s the way we do things here” excuses. More recently I see the “Cargo Cult” approach to things: “The books say this is the way to do it, so this is what we do”. I’ve seen a lot of tricks suggested to fix problems with Daily Stand-Ups (like using a 10-lb talking-stick to keep things short) and feel that whenever you need to resort to a “trick” like that you probably should be looking for a root cause instead.
What do you think? Are Daily Stand-ups Harming Your Team?
Life, Liberty, and the Pursuit of Agility » Blog Archive » Is The Daily Stand-Up Harming Your Team?:
[…] Agile Links « Mob Programming – It’s what’s for breakfast! New Version of Are Daily Stand-Ups Harming Your Team? […]
2 January 2013, 3:08 pmTom Howlett:
Thanks for this, it’s got me thinking about what’s missing from our daily interactions and collaboration that the standup replaces. Our standup often catches missed opportunities for helping each other on stories that were completed the previous day. They often cause us to go back and revisit the story. If those interactions had happened sooner we would have learn’t faster and we’d be spending more time doing the right thing. This problem is partly alleviated by having a 3-amigos get together before a pair start a story, but perhaps that should involve a couple of minutes with the whole team. I guess taking this further takes us to your idea of mob programming and the whole team working on each story.
4 January 2013, 6:45 amLanooba:
I’m happy to have read your thoughts about the standup, following our lively tweet on the subject.
I find myself agreeing with many of your points, yet my conclusion brings me to the fact that the standups actually help reduce waste.
How?
1. It reduces the amount of meetings generated by stakeholders (i.e. non-team members) asking for general status updates
2. It helps plan the day. I’ve worked with distributed and co-located teams and in all experiences, there’s still a need to step back and say “so what are we focusing on today?”
3. It reinforces the face-to-face communication value of the Agile manifesto. yes, information radiators such as task boards are great, but nothing beats hearing the dialogue
Through my own learning journey, and by talking with people such as yourself, I’ve also learned to overcome those harmful habits you’ve described. Yet, the conclusion has been a more focused, shorter, valuable standup – not its elimination.
Anyway, this is great information. And as you’ve stated, there is always value in questioning tradition so we can find ways to improve them.
4 January 2013, 10:11 amDiana Larsen:
Hi Woody
17 August 2013, 12:39 pmI’m looking forward to a conversation about this during Agile Open SoCal! What happens when we go to the next “why?” Why do we need communication and alignment? I think you might get to something like: so we can spread learning and discoveries throughout the team. As you’ve noted there are many ways to accomplish this. Using Retrospectives for examining the efficacy of every team practice, including Retrospectives(!), is really the point isn’t it? 🙂 Thanks for the refactoring.